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REMARKS 

Claims 1-52, 54-69, 71-96, 98-115, 117-142, 144-159, 164-166, 168-170, 179-180, 182, 
185-187, 189-190, 194-195, 197, 205-206, 209-210 are pending. Claims 1, 64, 159, 182, and 
197 are amended here. Applicant respectfully requests the Examiner to reconsider all the 
outstanding rejections based on the reasons demonstrated here. Applicant respectfully requests 
the Examiner to withdraw the rejections based on the reasons demonstrated. In the event, the 
Examiner is not persuaded and maintains any rejections. Applicant requests the Examiner to 
indicate them with greater specificity. 

Relevant Prosecution History 

First, the present claims are rejected based solely on U.S. Patent No. 5,655,085 issued to 
Ryan et al. ("Ryan '085"). Ryan '085 is a continuation-in-part of U.S. Patent No. 5,673,402 
issued to Ryan et al. ("Ryan '042"). The different subject matter in Ryan '085 (from Ryan '402) 
is directed to "illustrations of insurance" that can be produced rather than "illustrations of 
collateral used to repay a mortgage," which was disclosed in Ryan '402. Other than that 
difference, the methods and systems described in both the Ryan patents ('085 and '042) that are 
used to generate these illustrations of "insurance" and "collateral used to repay a mortgage," are 
substantially similar, if not identical. During original prosecution of Applicant's parent U.S. 
Patent No. 5,987,434, Ryan '402 was the only reference asserted to reject the claims. Applicant 
demonstrated the differences between Ryan '402 and the claims in the application of the '434 
patent, which resulted in issuance of the '434 patent. Since issuance, U.S. Patent No. 5,987,434 
has undergone two separate re-examination proceedings, the most recent confirming all claims as 
issued (Control Nos. 90/007,498 cS: 90/008900). 

The present application is a continuation of U.S. Patent 6,072,076, which is a 
continuation-in-part of U.S. Patent 5,987,434. Applicant demonstrates here the reasons by which 
the present, rejected claims are also distinct from Ryan '085, for reasons that are largely similar 
to those urged previously to overcome Ryan '402 during prosecution of U.S. Patent 5,987,434 
and its claims. Applicant respectfully contends that Ryan '085 is similar to Ryan '042. 
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35 U.S.C. §103 Rejections 

Claims 1-52, 54-69, 71-96, 98-115, 117-142, 144-159, 164-166, 168-170, 179-180, 182, 
185-187, 189-190, 194-195, 197, 205-206 and 209-210 stand rejected under 35 U.S.C. § 103(a) 
as being unpatentable over Ryan et al. (U.S. Patent No. 5,655,085) in view of Official Notice. 
Applicant respectfully traverses this rejection. 

A. Governing Criteria 

For rejections under 35 U.S.C. § 103, the establishment of a prima facie case of 
obviousness requires that all the claim limitations must be taught or suggested by the prior art. 
MPEP § 2143.03. The establishment of a prima facie case of obviousness requires that the 
claimed combination cannot change the principle of operation of the primary reference or render 
the reference inoperable for its intended purpose. MPEP § 2143.03. 

The Supreme Court set the standard for evaluating obviousness in its recent decision 

(KSR International Co. v. Teleflex Inc. et al. (550 U.S. 127 S. Ct. 1727 (2007)) to be "expansive 

and flexible" and "functional." However, the standard is not controlling, rather, the various 

noted factors only "can" or "might" be indicative of obviousness based on the facts. The 

Supreme Court in KSR enunciated the following principles: 

"[w]hen a work is available in one field of endeavor, design incentives and other 
market forces can prompt variations of it, either in the same field or a different 
one. If a person of ordinary skill can implement a predictable variation. Section 
103 likely bars it patentability. For the same reason, if a technique has been used 
to improve one device, and a person of ordinary skill in the art would recognize 
that it would improve similar devices in the same way, using the technique is 
obvious unless its actual application is beyond his or her skill. . ..[A] court must 
ask whether the improvement is more than the predictable use of prior art 
elements according to their established functions. 

Simply using the benefit of hindsight in combining references is improper. In re Lee, 277 F.3d 

1338, 1342-45 (Fed. Cir. 2002); In re Deminski, 796 F.2d 436, 442 (Fed. Cir. 1986)). The 

Supreme Court while recognizing the need "to guard against slipping into the use of hindsight," 

acknowledged the following principles: 

[rjejection on obviousness grounds cannot be sustained by mere conclusory 
statements; instead, there must be some articulated reasoning with some rational 
underpinning to support the legal conclusion of obviousness. 
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[I]t can be important to identify a reason that would have prompted a person of 
ordinary skill in the relevant field to combine the elements in the way the claimed 
new invention does. 

One of the ways in which a patent's subject matter can be proved obvious is by 
noting that there existed at the time of invention a known problem for which there 
was an obvious solution encompassed by the patent's claims. 

Rather, obviousness is to be determined from the vantage point of a hypothetical person having 

ordinary skill in the art to which the patent pertains. See 35 U.S.C. § 103(a). The legal construct 

also presumes that all prior art references in the field of the invention are available to this 

hypothetical skilled artisan. In re Carlson, 983 F.2d 1032, 1038, 25 USPQ 2d 1207, 1211 (Fed. 

Cir. 1993). The Supreme Court in KSR stated that: 

a patent composed of several elements is not proved obvious merely by 
demonstrating that each of its elements was independently, known in the prior art. 

An examiner may often find every element of a claimed invention in the prior art. 
"Virtually all [inventions] are combinations of old elements." Environmental Designs, Ltd. V. 
Union Oil Co., 713 F.2d 693, 698, 218 USPQ 865, 870 (Fed.Cir. 1983), cert, denied, 464 U.S. 
1043 (1984); see also Richel, Inc. v. Sunspool Corp., 714 F.2d 1573, 1579-80, 219 USPQ 8, 12 
(Fed.Cir. 1983). If identification of each claimed element in the prior art were sufficient to 
negate patentability, very few patents would ever issue. Furthermore, rejecting patents solely by 
finding prior art corollaries for the claimed elements would permit an examiner to use the 
claimed invention itself as a blueprint for piecing together elements in the prior art to defeat the 
patentability of the claimed invention. Such an approach would be "an illogical and 
inappropriate process by which to determine patentability." Sensonics, Inc. v. Aerosonic Corp., 
81 F.3d 1566, 1570, 38 U.S.P.Q.2d 1551, 1554 (Fed.Cir. 1996). In other words, the examiner 
must show reasons that the skilled artisan, confronted with the same problems as the inventor 
and with no knowledge of the claimed invention, would select the elements from the cited prior 
art references for combination in the manner claimed. The Supreme Court in KSR has also 
stated that: 

[o]ften, it will be necessary for a court to look to interrelated teachings of multiple 
patents; the effects of demands known to the design community or present in the 
market place. 

Further, the Supreme Court states that: 
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The Court relied upon the corollary principle that when the prior art teaches away 
from combining certain known elements, discovery of a successful means of 
combining them is more likely to be nonobvious. 



B. Ryan does not automatically input a plurality of client records without human 
intervention between input of the respective client records. 

1. Applicant traverses Examiner's Official Notice . 

With respect to this limitation, the Examiner has taken Official Notice stating: 

With respect to the newly amended feature of automatically inputting into 
the one or more associated databases a plurality of client records without human 
intervention between input of the respective client records, the client records 
comprising client data on specific entities. Ryan teach in Block 140, retrieving 
information regarding prospective insured(s)' from various stored tables 
(databases). Ryan is silent as to automatically without human intervention 
inputting the respective client records. Official Notice is taken that it is old and 
well known to automatically without human intervention to perform any known 
manual functions such as automatically making payments and entry of payment 
on an account. It would have been obvious to a person of ordinary skill in the art 
at the time of Applicant's invention to have included in the system of Ryan's 
retrieval of the information from the various stored tables (databases) for the 
process to have been performed automatically without human intervention 
because such a modification would ease the input process by making it faster and 
easier. Office Action, p. 4. 

Applicant respectfully traverses the Examiner's Official Notice that it is old and well known to 
automatically, without human intervention, perform any known manual functions as applied to 
the present invention as claimed. The Official Notice is not properly based upon common 
knowledge and no documentary evidence has been entered into the record to support such a 
finding. See MPEP 2144.03 ("Any rejection based on assertions that a fact is well-known or is 
common knowledge in the art without documentary evidence to support the examiner's 
conclusion should be judiciously applied. Furthermore, as noted by the court in Ahlert, any facts 
so noticed should be of notorious character and serve only to 'fill in the gaps' in an insubstantial 
manner which might exist in the evidentiary showing made by the examiner to support a 
particular ground for rejection. It is never appropriate to rely solely on common knowledge in the 
art without evidentiary support in the record as the principal evidence upon which a rejection 
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was based. See Zurko, 258 F.3d at 1386, 59 USPQ2d at 1697; Ahlert, 424 F.2d at 1092, 165 
USPQ 421."). Applicant submits documentary evidence to the contrary as discussed below. 

First, "automatically making payments and entry of pajmient on an account" has nothing 
to do with the present invention as claimed. Applicant respectfully submits this statement is 
irrelevant and inapplicable to the present claims. 

Second, the parent patent, U.S. 5,987,434, by virtue of its initial examination and 

subsequent two re-examinations, is ample evidence that a high volume system as the one 

presently claimed in the parent '434 Patent and here is not old and well known. For example. 

Applicant draws the Examiner's attention to statements in the '434 Patent's original prosecution 

on this limitation. The Examiner's statement of reasons for allowance specifically stated: 

Prior art of record taken alone or in combination fails to teach or suggest a 
decision criteria to select a subset of the financial products for each of the clients 
appropriate for that client taken in combination with an apparatus for using client 
information about the clients in the form of a plurality of client records to 
automatically select and present financial products appropriate for each of the 
clients as recited in independent claims 1, 8, 14, 15, 16, 19, 20, 21, 22, 23, 25, and 
28. 

Prior art of record taken alone or in combination fails to teach or suggest 
to select a subset of the financial products for each of the clients appropriate for 
that client using the client information, the financial products information, and the 
decision criteria and preparing a client communication for each of the clients 
which identifies the subset of the financial products for that client as taken in 
combination with a method for using client information about client comprising a 
plurality of client records to automatically select and present financial products 
appropriate for the clients as recited in independent claims 2, 35, 41, 42, 43, 46, 
47, 48, 49, 50, 52, and 55. '434 Notice of Allowability, pp. 2-3 (Exhibit V). 

In the first re-examination of the '434 Patent (Control No. 90/007,498), the Statement of Reasons 

for Patentability and/or Confirmation stated: 

Claims 1, 2, 8, 15, 16, 21, 22, 23, 25, 28, 35, 42, 43, 46, 48, 49, 55 and 
those that depend therefrom are confirmed because, but not necessarily limited as 
the only reason, the prior art patent and printed publications within this 
reexamination proceeding fail to disclose, teach or suggest, singly or in 
combination, the inputting means automatically inputting the plurality of 
client records without human intervention between input of the respective 
client records as the Patent Owner has argued in the remarks within this 
reexamination proceeding which is also incorporated herein as part of the 
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reason for confirmation. Control No. 90/0007,498, Notice of Intent to Issue Ex 
Parte Reexamination Certificate, p. 40 (emphasis added) (Exhibit W). 

While the present claims and the claims of the '434 Patent are distinct, they share this particular 

limitation and are distinct over Ryan for similar reasons as demonstrated herein. 

Third, as further evidence that the Examiner' s Official Notice is not proper because its 

basis was not common knowledge. Applicant submits an example of the help screens for two 

insurance illustrations systems, one in use today, and one in use around 1999. See Exhibits A-T 

(Exhibits A-L demonstrate Lincoln National's Designit Platform in use today; Exhibits M-T 

demonstrate a system used by US Life around 1999). As can be seen from the screenshots and 

help screens of the respective systems, these insurance illustration systems operate in a manner 

similar to the system disclosed in Ryan. Taken as a whole, the Exhibits provided by Applicant 

are evidence that in 1999 and even today, insurance illustration systems were capable only of 

generating illustrations one at a time through extensive manual use by an insurance agent . Using 

Lincoln National's Designit Platform as an example. Exhibit A, reveals that it is an insurance 

agent that must choose the type of product to illustrate. With regard to selecting a product to 

illustrate, help screens illustrated in Exhibits A & B screens state: 

On the left hand side of the next screen you will see a list of Lincoln Insurance 
Products, Sales Concepts and other tools. Click on the one that you want. Exhibit 
A. 

Once you have selected the product from one of the lists, double click on it and a 
new illustration will open up. You may now begin input. Exhibit B. 

Once the agent selects a type of product, the illustration system then directs an agent to save 

client files as one would save a word processing document. Exhibit C states: 

Saving clients can be done several different ways, but we recommend setting up 
client files with the names of your clients similar to how you would save files for 
a standard Windows application (e.g.. Word files). 

Multiple illustrations for multiple products for one client must be manually copied from one 

design to another. Exhibit E states: 

If you would like to run several illustrations for the same client with variations on 
them, you can copy the original design and then make edits. To accomplish this: 

• enter all necessary information 

• make all product design selections 
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• click on Copy this design. 

This will allow you to carry over all information to a new illustration and then 
make changes accordingly. This allows you to have several active illustrations 
for the same client simultaneously and allows you to compare premiums for the 
different designs. 

When the agent has run an illustration, the agent has the ability to: 

• Calculate a "Quick Preview" premium summary 

• View "Results and Warnings" ledger summary 

• Select and Preview reports on screen 

• Print all or selected reports 

All these commands can be activated from the right navigation bar of any product 
design. Exhibit!. 

While it does not exactly match in functionality, the Quick Preview function of this illustration 
system is analogous to Figs. 16-18 of Ryan. Furthermore, the "Print all" or selected reports 
functionality of this illustration system is analogous to Ryan's printing options shown in Fig. 3B- 
8. 

By way of yet another example, US Life's Exhibits N-Q, show the screens an insurance 
agent must use to manually enter information regarding the proposed insured. These screens are 
equivalent to Figs. 5-8 of Ryan, whereby an insurance agent manually enters an insured's 
information. Exhibit R shows that to get output from US Life's system, an agent must manually 
click on the pages of interest. Exhibit S reveals that if an insurance agent desires to run another 
illustration for a new insured, the agent must click the "New" button. Client information is 
edited by typing over existing data. Exhibit T reveals that the printing system for the illustration 
software is the same system used as the commercial operating system, Windows. Again, this 
functionality is very similar to Ryan's printing options as shown in Figs. 3B-8. 

What is important to note in these examples is that, even today, an agent must manually 
direct the process of illustrating a particular insurance policy. As with Ryan, key facts to note 
with these illustration systems are: (1) the agent is entering each piece of information into the 
system; (2) the information entered is for one client and a possible co-Insured; and (3) human 
intervention is required not only between the gathering of the information for a specific client 
and printing of a specific illustration, but for each separate client for who the system would 
produce an illustration. Therefore, Applicant has demonstrated here, that what the Examiner 
believes is common knowledge, is not common knowledge, even today. It appears to be common 
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knowledge to the Examiner only because the Examiner is using hindsight prompted by 
Applicant's disclosure. Therefore, the Official Notice is not properly based on common 
knowledge. 

2. Ryan does not teach the limitation . 
Notwithstanding the Official Notice, which is not based on common knowledge, Ryan 
teaches away from the present invention as claimed. Ryan is a system that prepares insurance 
illustrations for an insurance agent, whereby the insurance agent enters and prints one client 
record at a time. In other words, a client walks into an insurance agent's office and requests life 
insurance. The agent solicits information from the client and enters that information manually 
into the system of Ryan. An illustration is calculated and provided to the client. The Examiner 
ignores the Ryan reference as a whole in narrowly citing Block 140. Block 140 refers to Fig. 
3B-4, which is a schematic representation of the insurance illustration function of the system. 
Ryan states 

in Block 140, the system retrieves all components needed for a projection of life 
insurance values: product- specific data from data tables, stored by product and 
carrier; information regarding the insured(s) and information regarding the 
prospective insured(s)' life insurance needs and other personal information as 
solicited and stored in FIG. 3B-1. Col. 19, line 67 - col. 20, line 6. 

The information retrieved is not from a plurality of input client records, but from the Applicant's 

data manually input by an insurance agent about the client and a possible co-insured (e.g., a 

married couple). See Fig. 3B-1. The insurance illustration is then run for one client. 

With respect to Fig. 3B-1, which reveals the flowchart for generating a new applicant 

insurance application, Ryan states 

Block 76 leads to Block 78, which solicits the type of policy the user would have 
selected as displayed on the User Screen 2. The user may select to illustrate either 
a joint and survivor life insurance policy or an individual life insurance policy. It 
is a joint and survivor policy, the system will require policy information for each 
of two insureds. This is because a joint and survivor policy pays a benefit only 
upon the death of both insureds. Such policies are often used in estate planning 
for the payment of estate taxes upon the death of, for example, a married couple 
or a father and a daughter. Such policies are often used to assure that an estate 
has sufficient liquid assets to pay estate taxes. In Block 80, Solicit: Insureds 
Information; Employer Information, as as shown in Screens 3 and 4, the system 
solicits the Prospective Insured's information including, but not limited to the 



Page 42 of 52 



Application No. 



09/592,086 



Insured's home address and telephone number, age, sex, and date of birth, and 
place of work. In Block 82, and as depicted by Screen 5, the system goes on to 
solicit information regarding the prospective Insured's Health. These general 
question regarding the prospective insured's health permit carriers to segment 
prospective policy applicants into preferred and non-preferred risk and thereby 
provide a more accurate projection of policy charges. . ..In Block 84 through 86, 
the same questions are repeated for the prospective co-Insured in the Joint and 
Survivor branch of the logic. 

If the response to the question posed in User Screen 2 is "Individual" then 
the system goes instead to Block 88, Solicit Insured Information; Employer 
Information and Block 90, Solicit Insured Answers to Four Underwriting 
Questions. This information will be used likewise by the system to determine 
whether the applicant(s) is (are) a preferred or non-preferred risk, through 
comparison with specific desired responses, stored by product in System Data 
Base 22. 

Once this information has been obtained, the system goes on to solicit 
what kind of illustration the user would like in Block 92, Solicit Insurance 
Requirements. An example of the Screen that appears in front of the user appears 
in Screen 6 Insurance Requirements — Insured. The system requires the user to 
designate two out of three key variables needed in the illustration of a life 
insurance policy. The user must enter onto the screen some combination of the 
Minimum Death Benefit, Cash Value (and year the Cash Value should be 
attained), and premium amount. For example, if given Death Benefit and Cash 
Value amounts, the system finds for any product stored in the system that amount 
of Premium (and the Number of Years it would be payable) needed for the system 
to achieve that goal. Similarly, if given the annual Premium, the Number of 
Years for which it would be paid and the Death Benefit desired, the system 
projects the Cash Value that would be associated with such a transaction. 

In Block 94, Solicit Additional Coverages, the system solicits any 
additional coverages desired by the client. . ..Screen 7, for example, shows several 
riders potentially made available by the system. . ..This screen has an 
electronically highlighted area, a "form" or blank, appearing next to the 
description of each additional benefit. This "form" is filled in by the user with a 
dollar amount. . ..Screen 8 solicits information as to where the policy will be 
issued. 

In Block 96, Store, all the information regarding the prospective Insured 
and, if one exists, the co-Insured, is stored in System Data Base 22 for later use by 
the system. Col. 17, line 12 - col. 18, line 30. 

The "later use" Ryan refers to is the calculation and production of a single insurance illustration 
for the information entered as shown in Fig. 3B-4. Key facts to note here are: (1) the agent 
enters each piece of information into Ryan's system; (2) the information entered is for one client 
and a possible co-Insured; and (3) human intervention is required not only between the gathering 
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of the information for a specific client, but for each separate client for who the system would 
produce an illustration. 

Nowhere does Ryan contemplate the input of a plurality of client records without human 
intervention between input of the client records as acknowledged by the Examiner who stated 
"Ryan is silent as to automatically without human intervention inputting the respective client 
records." Because of the intensive manual input and decision-making needed by an insurance 
agent, Ryan's system is incapable of providing such functionality. This is because Ryan is not 
intended to provide offers of insurance, but illustrations of insurance. Applicant respectfully 
submits that this lack of functionality and disclosure teaches away from the present invention as 
claimed. 

The present claims are directed to a continuous method that considers client and financial 
data, determines whether to offer a product for a specific entity, creates and generates an offer 
for the determined product, and then repeats the process for each client record. A processor 
performs all these steps without input from an agent enabling the Applicant's method and system 
to produce a high volume of offers in a limited amount of time. Accordingly, for this reason 
alone. Applicant submits the claims are allowable and requests withdrawal of this rejection. 

C. Ryan does not automatically generate each of the plurality of communications 

without human intervention between the generation of each communication for each 
specific entity. 

To more particularly emphasize the difference between Ryan and the present claims. 

Applicant has amended the claims. Ryan is incapable of, and teaches away from, generating a 

plurality of communications without human intervention between the generation of each 

communication. Ryan specifically states^: 

[tjurning to Fig. 3B-8 at Block 166, the values relevant to the computation of an 
illustration are generated, then displayed at the user's terminal in Block 168, and 
stored in the Database 26. The user can select a number of options: Print 
Illustration? 172, which will print the information on the Local Printer 30 via 
Block 174; Print and Mail Illustration? 176, which will print the illustration on 

^ Though this quote is taken verbatim from Ryan '085, the Block numbers refer to Block numbering from its parent 
patent Ryan '402. Other than the Block numbering the schematic appears to match the description. Any reference 
to the Figures should be understood to be those in Ryan '085. 
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the Central Printer 20 for mailing to a requested address via Block 178; and Make 
Application Using This Illustration? 180, which merges illustration results for 
further analysis or review. (Col. 22, lines 25-36)(emphasis added). 

No other mode of output is disclosed by Ryan. The only way to produce an illustration is for a 
user to choose Print, Print and Mail, or Make Application. Thus, Ryan discloses a system that is 
capable only of producing communications (i.e. illustration) one at a time , such production 
directed only by a user, and certainly not by a processor. The Examiner's statements that Ryan 
is a "computerized system which outputs an offer for a particular product, and then moves on to 
the next client" and "multiple or various/many/high volume of offers for multiple clients are 
possible" are directly at odds with Ryan's disclosure. As the above citation reveals, the system 
of Ryan is solely directed by a user and possesses no capability to "move on to the next client" 
on its own. In the context of Ryan, moving on to the next client encompasses the agent repeating 
the process of interviewing a client, manually inputting the client's data, and running an 
illustration. 

With respect to this element, the Examiner states 

Applicant argues that Ryan is not an automated process and that in Ryan, the 
illustration is chosen manually. The Examiner disagrees with Applicant because 
in Ryan, the user's information is inputted into the system, and the processor 
chooses which illustration and variable information to be outputted based on the 
user's information. The type of policy or variable information is chosen by the 
processor based on the information entered. Office Action, p. 7. 

However, Ryan's processor does not choose which illustration to run and output. See e.g.. Fig. 
17-18. As shown above, the agent selects through Ryan's interface a policy to illustrate and then 
selects whether to print the illustration. Ryan certainly does not select a type of policy; the type 
of policy, universal life insurance, has already been chosen. 

Accordingly, for these reasons. Applicant submits the claims are allowable and requests 
withdrawal of this rejection. 

D. Ryan does not determine whether to offer a financial product or service to specific 
entities. 

Ryan does not possess this decision-making ability, as does the present invention as 
claimed. In the present invention as claimed, client data, financial product data (not complete 
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financial products) are considered by a processor to first determine whether a product should be 
offered to a particular client. In other words, when client record data are automatically input into 
the system, no product or product characteristics have been predetermined to offer any of the 
clients. One or more databases contain data which is used to create a custom offer for a 
particular client; however, the product data does not exist as discrete products, rather the product 
data exists as pieces of data (i.e., product characteristics) to makeup any particular product. See 
Specification, p. 19, lines 3-28. The fact that this data may pertain to one or more products does 
not mean that this information must exist as a discrete product in any sense. 

The system uses decision criteria applied against client data and financial product data to 
first determine whether a product should be offered to a particular client. For example, within a 
particular client's data, a credit score may be consulted or calculated. It may be determined that 
a range of low credit scores do not merit the offer of any product, a range of medium scores 
merit the offer an insurance product, and a range of high scores merit the offer of a credit and 
insurance product. It is important to note that the system has not yet determined a complete 
product, but whether a product and the type of product are to be offered. Ryan possesses none of 
this capability . 

Ryan does not determine whether an insurance policy is offered, but which one to 
illustrate, i.e., a product determination has already been made and outside of Ryan's system. To 
allegedly show this feature's disclosure in Ryan, the Examiner has cited Figure 7. 

Fig. 7 
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Figure 7 is a screen to enter a client's information for one purpose only — to illustrate a life 
insurance product. This information is not used to determine whether a life insurance product is 
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made, but to match the information entered with which universal life product to illustrate. As 
stated previously, once a user (i.e., an agent) has decided to utilize Ryan's system, the 
determination whether to offer a financial product or service to an entity necessarily has already 
been made — to offer universal life insurance — by a human. Ryan has no other capability other 
than to match universal life insurance products with the client's entered information and 
illustrate that product. Thus, if a human agent has not already made a determination to offer 
universal life insurance, then universal life insurance will not be offered to the client and Ryan's 
system and method are useless. Ryan's system cannot make a determination as to whether a 
financial product is offered to a specific client. 

Moreover, Ryan requires an agent to specify everything about a product except the 
premium, for example, the policy type (individual or joint & survivor), the minimum death 
benefit, the cash value and year attained, the yearly payment, the waiver of premium annual 
benefit, the accidental, additional, and spouse death benefits, and the state of issue. See Ryan 
'085, Figures 6-14. In order to produce an illustration or application, a human (i.e., not a 
processor) must choose an actual insurance policy. See Figures 13, 16-18. At every interaction 
with Ryan's system, the user is continually providing input to the processor throughout Ryan's 
process. The processor makes no determination as to whether to offer a product or even the type 
of product to be illustrated. 

Additionally, with respect to this element, the Examiner states 

Applicant argues that Ryan doesn't teach using said processor to consider client 
data on the specific entities. The Examiner wants to point out that in the instant 
application, certain or a pool of products or services have to be selected that can 
be offered to the customers. There's no possibly way that the system can select 
product/services out of thin air without having some sort of database of products 
or services that the processor can choose from and then having a processor match 
the client's information to one of the products/services. If that's not the case then 
Applicant must show in the specification how a processor selects a 
product/service without having a product/service database of known 
products/services. The Examiner wants to point out that in Ryan, based on the 
user's information a product/service such as insurance product or the like is 
created for the client. The processor determines what type of insurance policy, 
limits and price to offer to the particular client based on the entered information. 
The product/service is customized by a processor. Office Action, p. 6. 
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However, the Examiner has mischaracterized the Applicant' s argument. Applicant has not 
argued that Ryan does not teach using a processor to consider client data on the specific entities 
(Applicant has taken no such position either way). Applicant argued previously and continues to 
argue above that Ryan does not teach using a processor to determine whether to offer a financial 
product or service by considering client data on specific entities. In Ryan, the determination of 
whether to offer a product is made by an agent or something else not disclosed by Ryan. 

Furthermore, Ryan is a system that illustrates universal life products; it does not produce 
nor create offers for financial products or services. It is well known that, generally, an insurance 
illustration, which is mandated by law, is produced so that clients understand the performance of 
a particular insurance policy. (See Exhibits A-L, M-T and Exhibit U). The illustrations are 
hypothetical in nature and are based on assumptions made by a particular insurance company. 
Once an agent has manually entered the needed parameters into Ryan's system (see Fig. 14), 
Ryan provides a list of available policies from which an agent must choose to illustrate. See 
Figs. 14-18. Nowhere in this process has Ryan's system chosen a policy to offer the customer. 
It merely is an advanced matching engine that removes the need for the agent "to go to many 
different insurance companies to request quotes... [and] conduct lengthy and time-consuming 
analyses to establish which was the best product for the customer." Ryan '085, col. 2, lines 17- 
23. Again, Ryan displays a number of policies whereby the agent then selects the policy to 
illustrate. Ryan does not disclose any decision-making ability to determine whether to offer a 
particular financial product or service. 

E. Ryan does not teach a processor using client-specific decision information to 

automatically select parts of variable information from at least two different 

databases with the client data and the financial product data to determine the 

variable information specific to each specific entity and select the parts of the 

variable information determined for inclusion in a specific communication 

formulated to express an offering for the determined financial product or service or 

both for the specific entity. 

The Examiner states 

in Block 140, the system retrieves all components needed for a projection of life 
insurance values: product- specific data from data tables, stored by product and 
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carrier; information regarding the insured(s) and information regarding the 
prospective insured(s) life insurance needs and other personal information as 
solicited and stored in FIG. 3B-1 see Abstract. Office Action, p. 3. 

suggests the element of the claims. Applicant disagrees. 

Ryan is not emplojdng client- specific decision information to select parts of variable 
information to determine the variable information specific to a specific entity or variable to be 
included in an offering for a particular product. For example, in Block 140 of Fig. 3B-4, Ryan is 
retrieving information that is to be used for a life insurance projection of value. It is well known 
in the insurance industry that these life insurance projections are hypothetical and dependent on 
future performance of the insurance company, loans or other withdrawals by the insured, or other 
market based factors. See Exhibit U. These values are hypothetical and not an actual product or 
offer. Based on the policy selected by an agent, Ryan takes the stored information associated 
with the selected policy and the manually entered user information and uses this information in 
its computations for these hypothetical values. No client- specific decision information is being 
used to select any part of variable information. Rather Ryan is being employed as an advanced 
calculator to calculate certain values for the illustration. Even assuming, arguendo, that these 
values could be considered variable information; they are not part of a product offer . So, the 
"retrieval" of data cannot be interpreted as selecting parts of variable information using client- 
specific decision information as claimed. 

F. Ryan does not teach using an output module associated with the processor and 
configured to use at least one automated process to automatically compose the 
variable information comprising the parts determined to create the communication 
for each said specific entity such that at least one portion within the communication 
accommodates the variable information, wherein said variable information for each 
specific entity comprises at least partially a customized identification, specification 
and/or promotion of said financial product or said financial service or both wherein 
said variable information for each specific entity has at least some data that is 
different. 

With respect to this element, the Examiner states 
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Applicant argues that varying information is not the same as variable information. 
The Examiner disagrees with Applicant because based on the customer's 
information entered for a particular customer, the variable information or the 
information that is to be displayed or output is based on the product that will be 
offered [sic] to that particular client. Based on the product or service to be offered 
to the client, the text data changes. The processor determines what 
product/service to offer the client and it leads to the variable information that 
would be inserted into the communication/offer, etc. Office Action, p. 6-7. 

Varying information is not the same as variable information as claimed. Block 140 
gathers information from storage that was manually- entered information. This manually-entered 
user information is transferred to an illustration, unchanged. In other words, a processor does 
not determine this information nor does it vary the information. 

Contrary to the Examiner's statement, Ryan does not vary anything based on the user's 
personal information. Ryan calculates a result based on non- variable information and then 
publishes this result as an illustration. For example. Fig. 27A reveals that the processor has 
merely transferred manually-entered information to an illustration that summarizes the 
information. Obviously, if a user enters different information (e.g., the user decided to enter a 
higher death benefit or a different age), Ryan calculates a different result and outputs that result. 
However, if this occurs: (1) the method is now different from the claims because the user is 
manually changing the product and thus a processor is not making the determination whether to 
offer a product; (2) a human and not a processor, is varying the amounts of the insurance policy; 
and (3) an automated process cannot be considered to be composing the variable information 
because the only way it is varied is through modification by a user. 

Additionally, Ryan, in his 'Abstract' supports a teaching away from any disclosure of 
variable information determination. For example, the 'Abstract' states "[a] computer accesses a 
database into which data is written and from which data is read, the data including information 
regarding the life to be insured, general applicant information, insurance information and 
predetermined text data for incorporation into insurance illustrations." (emphasis added). 
Predetermined text data certainly does not constitute variable information as claimed. 

Ryan does not disclose "using an output module associated with said processor and 
configured to use at least one automated process to automatically compose said variable 
information comprising said parts determined to create said communication for each said specific 
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entity such that at least one portion within said communication accommodates said variable 

information, wherein said variable information for each specific entity comprises at least 

partially a customized identification, specification and/or promotion of said financial product or 

said financial service or both wherein said variable information for each specific entity has at 

least some data that is different." Previously, the Examiner stated: 

With respect to automatically composing the variable information. The Examiner 
wants to point out that Ryan teaches based on the user's information 
automatically displaying customized insurance policy with different amounts and 
terms based on the user's information. The display in itself is the output that is 
automatically displayed to the user based on the user's data. Advisory Action 
(10/31/08), p. 2. 

Ryan states 

[t]urning to Fig. 3B-8 at Block 166, the values relevant to the computation of 
an illustration are generated, then displayed at the user's terminal in Block 
168, and stored in the Database 26. The user can select a number of options: 

Print Illustration? 172, which will print the information on the Local Printer 30 
via Block 174; Print and Mail Illustration? 176, which will print the illustration on 
the Central Printer 20 for mailing to a requested address via Block 178; and Make 
Application Using This Illustration? 180, which merges illustration results for 
further analysis or review. (Col. 22, lines 25-36). 

However, only the values relevant to the computation are displayed on the terminal, Ryan does 
not disclose the step of "automatically displaying customized insurance policy with different 
amounts and terms based on the user's information" as the Examiner asserts. By assuming the 
Examiner's logic, and by virtue of the above quote, Ryan further teaches away from the present 
claims because the calculated values are not shown on the display screen. The only way Ryan 
discloses producing an illustration is for the user to manually choose how the illustration should 
be printed. This is certainly not an automated process. 

Accordingly, Ryan does not, and cannot, teach or suggest the present claims with or 
without combination of the Examiner's Official Notice, as it does not disclose or suggest each 
and every element of the claims as the Applicant has demonstrated here. Although the 
distinctions between Ryan and the present claims have been described with respect to claim 1, 
the argument and distinctions are similar with respect to the other pending independent and 
dependent claims. Therefore, Applicant respectfully requests withdrawal of this rejection for all 
pending claims. 
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Conclusion 

All of the stated grounds of rejection have been properly traversed. Applicant therefore 
respectfully requests the Examiner to reconsider all presently outstanding rejections and to 
withdraw them. In the event the Examiner does not find the claims here allowable, Applicant 
requests another interview with the Examiner to understand the Examiner's point of view. 



Respectfully submitted, 
BERRY & ASSOCIATES P.C. 
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